Data communication networks of today often utilize a network management framework that is based around the Simple Network Management Protocol (SNMP) described in detail in Internet Engineering Task Force Request for Comment 1157 entitled “A Simple Network Management Protocol (SNMP),” May 1990 (hereinafter referred to as RFC 1157), and in Internet Engineering Task Force Request for Comment 2570 entitled “Introduction to Version 3 of the Internet-standard Network Management Framework,” April 1999 (hereinafter referred to as RFC 2570), the contents of which are incorporated herein by reference.
FIG. 1 is a block diagram of a typical SNMP-managed network described in RFC 1157 and RFC 2570. In general terms, the network includes a SNMP manager referred to as a network management system (NMS) 10 coupled to a plurality of managed devices 12, 14, 16. The NMS 10 executes applications that monitor and control the managed devices 12, 14, 16. Each managed device 12, 14, 16 is a network node such as a bridge, hub, router, or terminal server that collects and stores management and configuration information as managed objects in its respective management information base (MIB) 12b, 14b, 16b. The managed objects may be hardware devices, configuration parameters, performance statistics, and the like.
Each managed device includes an SNMP agent 12a, 14a, 16a that retrieves information from the MIB associated with the device and returns the retrieved information to the NMS. Based on the retrieved information, the NMS makes a management decision for each managed device, and transmits a command to the appropriate SNMP agent to set a value of an appropriate managed object in the MIB based on the management decision.
One drawback to an SNMP-managed network is that the NMS 10 controls and manages each individual device on the network on an element-by-element basis. However, when multiple devices share common management and configuration parameters, such individual configuration may be tedious and redundant. In addition, the individual configuration of the managed devices may lead to inconsistencies in the configurations.
Another drawback to an SNMP-managed network is that the management decision making responsibilities for the various managed devices are centralized on one or more NMSs. In a typical management scenario, the central NMS polls each managed device and periodically retrieves relevant management parameters stored in the MIB via the SNMP agent. If the managed device detects an event that needs intervention from the NMS, the device typically sends a TRAP, that is, an interrupt signal, to the NMS. The NMS processes the TRAP and queries the managed device for the information it needs to evaluate the event and render a management decision. The SNMP agent in the managed device retrieves the information from the MIB and transmits the information to the NMS. The NMS renders a management decision based on the retrieved information and transmits enforcement steps to the SNMP agent according to its decision. However, as the number of managed devices on the network scales, so does the processing power needed for the centralized NMS and the traffic between the NMS and the SNMP agents, often resulting in increased processing costs and delays in the making and enforcement of management decisions.
Accordingly, what is desired is a network management platform that allows the making and enforcement of network management decisions over multiple network devices in an efficient and consistent manner. What is further desired is a network management platform that is scalable as the size of the network devices increases.